POV-Ray : Newsgroups : povray.programming : cleaning source code from warnings troubles : Re: cleaning source code from warnings troubles Server Time
28 Jul 2024 08:31:12 EDT (-0400)
  Re: cleaning source code from warnings troubles  
From: Warp
Date: 23 Sep 2002 08:11:49
Message: <3d8f0504@news.povray.org>
Thorsten Froehlich <tho### [at] trfde> wrote:
> Why should a compiler force the programmer to bloat the code?

  You are still acting like a warning was an error. The compiler is not
forcing you to do anything.

  And if you want to avoid "bloating the code", then don't use comments at
all and write everything with the minimal amount of whitespace.
  Writing extra code is not always bad, but can be all the contrary. If it
makes the code more clear, then it's good.

>  If those who
> specified the standards had intended to prevent implicit conversions they
> could have done so.  It is not the compiler writers job to second-guess
> those who made the standard nor those who write code following the standard.

  I don't understand why you deliberately misread what I said. I didn't
say that the compiler is preventing implicit conversions. I said that if
an implicit conversion is losing information, then that can be a programming
mistake and the compiler is warning about it.
  The compiler does not warn about converting from a smaller type to a
larger one. Why? (Reading your text one would get the impression that
it warns about those as well.)

> As I pointed out, it is good to have such a warning available, just like
> many other warnings; but this does not imply that legal code should cause
> any warning.

  Now I don't understand. First you say that it's good to have the warning
available, and immediately after that you say that it should not be issued.
Which is it?

> let me show this by a different example:  Does gcc issue a warning if

  I know that gcc does *not* warn about many things it should, and I could
list quite many things here if I wanted. However, I don't see how that is
relevant to the question that gcc *does* warn about some other things.

  I don't understand the ideology "if it doesn't warn about this, it shouldn't
warn about anything at all".

>> FILE* infile = fopen(...);
>> int fileID;
>> fread(&fileID, 4, 1, infile);
>> if(fileID != 'RIFF') { error("Wrong file type"); }
>>
>>  Will that work in a high-endian/low-endian system?

> Your example by itself is incorrect because writing any type to a file is
> specified to be implementation defined.

  I fail to see where does that code write anything to a file.

  But as you say, that code is not good, and the compiler warning about it
is only a good thing, don't you think?
  You are saying that the compiler should not warn about that (because it
will not warn if you compare the int you read from the file with a constant,
because that's just way too difficult for the compiler to catch).

> * The compiler writer has to assume the user of the compiler is a
> professional just like he is and knows what he is doing.  The compiler
> writer may not try to teach the compiler user by default.

  I am a professional. I make mistakes. The compiler has sometimes helped me
finding them.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.